>Eric Johnson | "The American Republic will endure until the day
>ejohnson@suna0.cs.uiuc.edu | Congress discovers that it can bribe the public
>eej37047@uxa.cso.uiuc.edu | with the public's money" - Alexis de Toucqueville
Humayun Lari
(lari@cs.unc.edu)
---------------------------
From: 3jean@maas-neotek.arc.nasa.gov (E.T.A.)
Subject: Temporary Memory in a CDEV
Organization: NASA Ames Research Center
Date: Sun, 14 Jun 1992 21:07:09 GMT
I'm writing a CDEV and running it under System 7. I've been having
problems with crashes and just now I realized that the stack is
colliding with the CDEV's heap since I allocate a large amount of
memory in the CDEV's application heap.
1. Is there a way to increase the heap size of my CDEV ?
2. Or is there a way to get a fairly large amount of temporary
memory from Multifinder that I could use ?
(I remember a Technical Note about Multifinder temporary memory but I
can't seem to find it right now. Isn't the temporary memory from
Multifinder limited -- i.e. handles are fake handles?)
Thanks in advance for any help you may be able to give on this.
- -Eric Anderson
3jean@maas-neotek.arc.nasa.gov
+++++++++++++++++++++++++++
From: ewylie@ocf.berkeley.edu (Elizabeth Wylie)
Date: 15 Jun 92 00:14:56 GMT
Organization: U. C. Berkeley Open Computing Facility
> 1. Is there a way to increase the heap size of my CDEV ?
>
> 2. Or is there a way to get a fairly large amount of temporary memory
> from Multifinder that I could use ?
1) First of all, your CDEV does not have its own heap. It runs in the Finder's heap under system 7 and in the DA Handler's heap under 6.x with multifinder. So you are already out some stack space the Finder is using. I make it a point
never to use more than 1K or so of stack space. Instead, call NewPtr or NewHandle to allocate the amount of memory you need in the heap. You will be responsible for dispos'ing of it when you are through.
2) There is a way, and it is documented in a technote somewhere (or maybe it's in Volume VI, I don't know). I do know that temp memory should only be used for a short amount of time and returned to multifinder as soon as possible. Since your control panel may be open for any length of time, using temporary memory may make it impossible for the user to launch a new application.
Organization: University of Waikato, Hamilton, New Zealand
In article <11gne0INNt6e@agate.berkeley.edu>, ewylie@ocf.berkeley.edu
(Elizabeth Wylie) writes:
>> 1. Is there a way to increase the heap size of my CDEV ?
>>
>> 2. Or is there a way to get a fairly large amount of temporary memory
>> from Multifinder that I could use ?
>
> 1) First of all, your CDEV does not have its own heap. It runs in the
> Finder's heap under system 7 and in the DA Handler's heap under 6.x with
> multifinder.
The part about System 7 is correct. Under System 6, control panels run
within the context of the Control Panel DA, so their heap context is the
same as for DAs under System 7 or MultiFinder: that is, the current heap is
the system heap.
> So you are already out some stack space the Finder is using.
> I make it a point never to use more than 1K or so of stack space. Instead,
> call NewPtr or NewHandle to allocate the amount of memory you need in the
> heap. You will be responsible for dispos'ing of it when you are through.
I just did a quick check with a control panel I wrote a long time ago, and
it turns out that Finder 7 sets the current heap to the system heap before
passing control to a control panel. Thus you shouldn't have to take special
action to allocate large or small amounts of memory: just call NewPtr and
NewHandle like you would normally expect to. Just remember that you *must*
dispose of blocks that you've finished with, or they will stay allocated until
the machine is shut down.
> 2) There is a way, and it is documented in a technote somewhere (or maybe
> it's in Volume VI, I don't know). I do know that temp memory should only be
> used for a short amount of time and returned to multifinder as soon as
> possible. Since your control panel may be open for any length of time,
> using temporary memory may make it impossible for the user to launch a new
> application.
I don't think that *allocating* the temporary memory itself is going to cause
much fragmentation, though *locking* it certainly will.
Lawrence D'Oliveiro fone: +64-7-856-2889
Computer Services Dept fax: +64-7-838-4066
University of Waikato electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
---------------------------
From: day_kevran@tandem.tandem.com (Kevran Day )
Subject: ?? Cobol Compiler for the MAC ???
Organization: Tandem Computers, Inc.
Date: Wed, 3 Jun 1992 19:55:14 GMT
Does anyone know of a Cobol Compiler for the MAC? APDA Catalog doesn't have one listed,
but hopefully that doesn't mean one doesn't exist!
- - Kevran Day
+++++++++++++++++++++++++++
From: owen@lloyd.Camex.COM (Owen Hartnett)
Organization: Camex Inc., Boston MA
Date: Mon, 15 Jun 1992 08:26:51 EDT
In article <1992Jun3.195514.6031@tandem.com> day_kevran@tandem.tandem.com (Kevran Day ) writes:
>Does anyone know of a Cobol Compiler for the MAC? APDA Catalog doesn't have one listed,
>but hopefully that doesn't mean one doesn't exist!
>
>- Kevran Day
>
This one runs under AUX only!
Acucobol-85, requires PMMU Mac, 4MB Ram and hard disk drive.
$400 to $2000 retail
Acucobol, Inc.
7950 Silverton Avenue, Ste. 201
San Diego, CA 92126
(619) 689-7220
(619) 566-3071 (fax)
Information from the 1992 macintosh Product Registry. I don't know
anything about the compiler.
- -Owen
---------------------------
From: oster@well.sf.ca.us (David Phillip Oster)
Subject: How do you disable the disk cache?
Organization: Whole Earth 'Lectronic Link
Date: Sat, 13 Jun 1992 03:52:24 GMT
How do you disable the cacheing of disk i/o to ram via program
control?
I remember reading that the Finder would turn off disk cacheing when it
did a file copy, because the copy would just flush anything useful in
the cache. The same article that said this described a way to turn the
cache on and off and query its current state so it could be restored,
but I don't remember where that article was. I searched the current
Developer's CD for "disk cache" without finding it.
I have a real reason, not just superstitious fear of the cache: I'm
asking because I've written a driver for a SCSI scanner. If the cache
is too large, then when the application that calls the driver writes a
buffer of scan data to disk, the disk i/o takes so long that the
scanner hardware times out and locks up.
+++++++++++++++++++++++++++
From: keith@taligent.com (Keith Rollin)
Date: 15 Jun 92 20:13:34 GMT
Organization: Taligent
In article <1992Jun13.035224.9474@well.sf.ca.us>, oster@well.sf.ca.us (David
Phillip Oster) writes:
>
> How do you disable the cacheing of disk i/o to ram via program
> control?
>
> I remember reading that the Finder would turn off disk cacheing when it
> did a file copy, because the copy would just flush anything useful in
> the cache. The same article that said this described a way to turn the
> cache on and off and query its current state so it could be restored,
> but I don't remember where that article was. I searched the current
> Developer's CD for "disk cache" without finding it.
>
> I have a real reason, not just superstitious fear of the cache: I'm
> asking because I've written a driver for a SCSI scanner. If the cache
> is too large, then when the application that calls the driver writes a
> buffer of scan data to disk, the disk i/o takes so long that the
> scanner hardware times out and locks up.
I think that Technote #81 is what you are looking for. I also have a rather
mysterious note written in my copy that says to "set bit 5 of ioPosMode to
inhibit caching." I don't know if this applies of PBRead, PBWrite, or both. Give
it a shot.
- --
Keith Rollin
Phantom Programmer
Taligent, Inc.
---------------------------
From: ozma@kuhub.cc.ukans.edu
Subject: Booleans & SIZE in THINK C (not related)
Date: 14 Jun 92 00:56:40 CDT
Organization: University of Kansas Academic Computing Services
Two problems programming with THINK C (although THINK C isn't necessarily the
problem - it't likely me).
I still can't rely on passing or returning Booleans in THINK C. Like:
Boolean CommandKeyIsDown (void)
{
/* GetKeys(), BitTst for Command Key Code, return result */
}
When I say: if (CommandKeyIsDown()) {, I never get a TRUE condition. Changing
the Boolean to a char isn't reliable either.
short CommandKeyIsDown (void)
{
/* same code with (short) casting of BitTst() */
}
The above works. Why not char or Boolean? Should these types be avoided as
conditionals? Sometimes as well, passing in a Boolean like:
void CalculateScore (Boolean drawIt)
{
/* blah, blah, blah */
}
Doesn't work. (This particular example isn't real and may differ some from the
functions that I've found fail.)
My seconds problem is, why can't I increase the size (SIZE) allocated to my
app? I added a SIZE resource (maybe I shouldn't have), but in any event, when
I try bumping it up to 2 megs (from 1 meg), THINK C doesn't give it the
additional meg. So, I bump the partition size up to 2 megs using THINK C's
menus (what is it, the Project Type menu?) - this doesn't give me the 2 megs
either. Mind you, I have 17 megs on my machine.
If it's of any consequence, THINK C 5.02, System 7.0.1 (Tuned), IIsi. If it's
anything other than mindless stupidity on my part, I'll post responses.
Thanks.
john calhoun
+++++++++++++++++++++++++++
From: ewylie@ocf.berkeley.edu (Elizabeth Wylie)
Date: 14 Jun 1992 08:41:57 GMT
Organization: U. C. Berkeley Open Computing Facility
> I still can't rely on passing or returning Booleans in THINK C. Like:
>
> Boolean CommandKeyIsDown (void)
> {
> /* GetKeys(), BitTst for Command Key Code, return result */
> }
>
> When I say: if (CommandKeyIsDown()) {, I never get a TRUE condition.
> Changing the Boolean to a char isn't reliable either.
There is one reason I can think of for this to fail:
Boolean KeyDown ()
{
KeyMap myKeys;
GetKeys (myKeys);
return (myKeys [whateverByte] & whateverBit);
}
I dont know off hand what bit to check of the key map. I do know that the
above code evalutes to a long and is then truncated to a Boolean. So, if you are testing bit 8 (for example) and that bit is set, the above test will evaluate to 0x100. BUT A BOOLEAN IS ONE BYTE. C knows this and truncates the result leaving you with 0x00. If this is what you are doing, you should do the following:
if (myKeys [whateverByte] & whateverBit)
return (TRUE);
else
return (FALSE);
Booleans are often thought of as being two bytes long, they are not. They are
padded to two bytes when used in structures so that every field is on an even
byte boundry.
As for passing Booleans, perhaps you are doing the same sort of thing-- passing
a two byte value that gets truncated to zero.
- -Elizabeth
.
+++++++++++++++++++++++++++
From: keith@taligent.com (Keith Rollin)
Date: 15 Jun 92 20:19:52 GMT
Organization: Taligent
In article <11f0olINNp2o@agate.berkeley.edu>, ewylie@ocf.berkeley.edu (Elizabeth
Wylie) writes:
>
> > I still can't rely on passing or returning Booleans in THINK C. Like:
> >
> > Boolean CommandKeyIsDown (void)
> > {
> > /* GetKeys(), BitTst for Command Key Code, return result */
> > }
> >
> > When I say: if (CommandKeyIsDown()) {, I never get a TRUE condition.
> > Changing the Boolean to a char isn't reliable either.
>
> There is one reason I can think of for this to fail:
>
> Boolean KeyDown ()
>
> {
> KeyMap myKeys;
>
> GetKeys (myKeys);
>
> return (myKeys [whateverByte] & whateverBit);
> }
>
> I dont know off hand what bit to check of the key map. I do know that the
> above code evalutes to a long and is then truncated to a Boolean. So, if you
are testing bit 8 (for example) and that bit is set, the above test will
evaluate to 0x100. BUT A BOOLEAN IS ONE BYTE. C knows this and truncates the
result leaving you with 0x00. If this is what you are doing, you should do the
following:
>
> if (myKeys [whateverByte] & whateverBit)
> return (TRUE);
> else
> return (FALSE);
>
> Booleans are often thought of as being two bytes long, they are not. They are
> padded to two bytes when used in structures so that every field is on an even
> byte boundry.
>
> As for passing Booleans, perhaps you are doing the same sort of thing--
passing
> a two byte value that gets truncated to zero.
>
> -Elizabeth
I agree. The following has worked fine for me with no problems ever:
